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TITLE OF THE INVENTION 
VIDEO-ON-DEMAND (VOD) MANAGEMENT SYSTEM AND METHODS 

CROSS-REFERENCE TO RELATED APPLICATIONS 
5 [0001] This application claims benefit of provisional 

Application No. 60/429,966, filed November 27, 2002, the 
disclosure of which is fully and expressly incorporated herein 
by reference. 

10 FIELD OF THE INVENTION 

[0002] The present invention relates to multimedia 
content distribution systems and methods, and specifically to 
multimedia content distribution systems and methods that manage 
the preparation, scheduling, and propagation processes for 

15 video -on- demand ("VOD") assets. 

BACKGROUND 

[0003] With the development of broadband technologies, 
cable and satellite television services are increasingly 
20 providing their customers with VOD services. In a typical VOD 
system, the cable or satellite multiple service/systems 
operator ("MSO") receives audiovisual content such as features, 
which may be movies, television shows, or other types of 
feature content, and the feature's associated previews and 
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graphics files (a feature and its associated previews and 
graphics files may be collectively referred to herein as 
"content") from content providers, stores the content locally, 
and then transmits the content to a viewer upon the viewer's 
5 request. Content providers generally transmit content to MSOs 
via satellite transmissions or via a high-speed terrestrial- 
based network using appliances commonly referred to as 
pitchers. To receive -the transmissions from the content 
providers, MSOs deploy a number of appliances commonly referred 
10 to as catchers. Catchers receive the transmissions from the 

content providers and, after receiving a complete file, relays 
the file to a VOD server. The VOD server then provides content 
to consumers of the MSO upon demand by the consumers . 

[0004] Because a particular MSO will receive 
15 transmissions from a number of different content providers, 

each of whom may use different formats when transmitting their 
own content, problems may arise when the MSO attempts to 
process content prior to providing the content to its 
consumers. For example, file processing problems may arise due 
2 0 to extensible markup language ("XML") formatting issues, such 

as, e.g., a content provider may place metadata associated with 
the content in its files that the MSO's system regards as non- 
compliant data. As a result, metadata provided by various 
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content providers may be inconsistent, unmanageable, or 
interpreted incorrectly when received by the MSO. Further, 
content providers and MSOs may use different and/or proprietary 
file transfer systems that may contribute to incompatibilities 
5 and transmission problems. Problems may also arise if a file 

contains corrupted data. As a result of the metadata issues as 
well as the file corruption issues, content may not be 
available on the VOD servers when scheduled. 

[0005] Receiving data streams from many content 
10 providers has also limited the data available to a MSO that may 
be used to monitor the flow of VOD assets through its system. 
As a result, MSOs currently spend an inordinate amount of human 
resources to manually monitor and intervene with content 
management. The problem of a lack of visibility of the flow of 
15 VOD assets is also exacerbated by current content distribution 
schemes in which a content provider may independently operate 
the content input portion of the distribution process, third 
party aggregators, distributors, and other enablers operate the 
encoding and metadata management portion, the content upload 
2 0 portion, and the download to catchers portion of the 

distribution process, and the MSOs operate the content 
distribution to end users portion of the process. That is, 
currently, a content provider may be responsible for providing 
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content and metadata, an aggregator, distributor, or other 
third party enabler may be responsible for combining the 
content and metadata, uploading the content to satellites, and 
then downloading the content to catcher appliances, and a MSO 
5 may be responsible for delivering content to its end users or 
consumers (references herein to "end users" are intended to 
refer to either an end user or a consumer) . Because of the 
current lack of visibility of the flow of VOD assets, content 
management problems are difficult to isolate and resolve by the 
10 MSO, the content providers, or any other party in the content 
distribution chain. 

[0006] Consequently, there is a need for systems and 
methods that allow a MSO and content providers to resolve 
transmission problems with regard to VOD content transmissions 
15 and to provide metadata that will comply with MSO requirements. 

[0007] There is also a need for systems and methods 
that offer greater visibility and control over the transmission 
of VOD content, thereby allowing proactive monitoring of the 
assets being transmitted within the system. 

20 [0008] There is also a need for systems and methods 

that offer greater visibility over the usage information of the 
content and that allow for proactive programming decisions 
based on the performance or usage of such content . 
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SUMMARY OF THE INVENTION 
[0009] The present invention is directed to methods and 
systems for managing and delivering metadata while providing 
5 visibility and control over such metadata and the transmission 
of the content associated with such metadata as well as the 
usage information associated with such content. 

[0010] In one aspect of the present invention a method 
of distributing content in the form of multimedia asset data 

10 files using a VOD management system is provided. A content 
provider and a MSO input the metadata associated with a 
multimedia asset data file into the VOD management system 
(unless otherwise noted, references herein to "metadata" refer 
to information of the associated multimedia asset data fil e s as 

15 defined herein, such as, e.g., title, date of theatrical 
release, summary of plot, cast, and crew, Motion Picture 
Association of America ("MPAA") rating, length, price per view, 
scheduling information, other XML data desired by a MSO, and 
the like, which may be obtained from data entry over a web 

20 application, CableLabs XML, or ingestion of legacy media asset 
management databases) . The VOD management system manages such, 
metadata. The MSO (and the content provider, to the extent 
permitted by the MSO) may access the metadata by accessing the 
VOD management system. The content provider then delivers the 
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multimedia asset data file to a MSO via satellite or other 
distribution system, such as tape delivery, disk delivery, a 
local network, or a terrestrial -based network. The MSO (and 
the content provider, to the extent permitted by the MSO) may 
5 monitor such delivery using the VOD management system. After 
the file is delivered to the MSO, the VOD management system 
delivers a schedule to a VOD server instructing the VOD server 
to request the metadata from the VOD management system and 
requesting the multimedia asset data file from the catcher to 

10 which it has been delivered. Then, the file is uploaded to the 
VOD server maintained by the MSO. The MSO (and the content 
provider, to the extent permitted by the MSO) may monitor such 
delivery using the VOD management system. The VOD management 
system generates usage reports relating to the usage of the 

15 multimedia asset data files by the end users of the MSOs * f or 
use by the MSOs (and the content provider, to the extent 
permitted by the MSO) to manage the delivery of multimedia 
asset data files. 

[0011] In another aspect of the present invention, a 
2 0 method of using a VOD management system to distribute 

multimedia asset data files from a plurality of content 
providers to a plurality of MSOs is provided. A plurality of 
content providers and a plurality of MSOs input metadata 
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associated with a plurality of multimedia asset data files into 
the VOD management system. The VOD management system manages 
such metadata. The MSOs (and the content providers, to the 
extent permitted by each MSO) may access the metadata by 
5 accessing the VOD management system. A plurality of content 
providers then deliver a plurality of multimedia asset data 
files to a plurality of MSOs via satellite or other 
distribution system, such as tape delivery, disk delivery, a 
local network, or a terrestrial -based network. The MSOs (and 

10 the content providers, to the extent permitted by each MSO) may 
monitor such delivery using the VOD management system. After 
the plurality of files are delivered to the MSOs, the VOD 
management system delivers schedules to VOD servers instructing 
the VOD servers to request the metadata from the VOD management 

15 system and requesting the multimedia asset data files from the 
respective catchers to which the files have been delivered. 
Then, the files are uploaded to VOD servers maintained by the 
MSOs, preferably using an asset URL assigned to each file. The 
MSOs (and the content providers, to the extent permitted by 

2 0 each MSO) may monitor such delivery using the VOD management 
system. The VOD management system generates usage reports 
relating to the usage of the multimedia asset data files by the 
end-users of the MSOs for use by the MSOs (and the content 
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providers, to the extent permitted by each MSO) to manage the 
delivery of multimedia asset data files. 

[0012] These and other objects and features of the 
present invention will be appreciated upon consideration of the 
following drawings and description. 

BRIEF DESCRIPTION OF THE FIGURES 
[0013] Figure 1 is a schematic diagram of the 
components of a VOD management system of the present invention. 

[0014] Figure 2 illustrates a price calculation process 
using pricing rules as implemented by the systems and methods 
of the present invention. 

[0015] Figure 3 is a schematic diagram of an asset 
distribution functional component of a VOD management system of 
the present invention. 

[0016] Figure 4 illustrates a workflow implemented by 
an asset distribution functional component of a VOD management 
system of the present invention. 

[0017] Figure 5 illustrates a workflow implemented by a 
content upload functional component of a VOD management system 
of the present invention. 
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[0018] Figure 6 is another illustration of physical 
components used to implement a VOD management system of the 
present invention . 

[0019] Figure 7 illustrates the implementation layers 
of one embodiment of a VOD management system of the present 
invention. 

DETAILED DESCRIPTION 
[0020] The present invention provides for closed loop 
VOD management systems and methods to ensure accurate and 
timely availability of VOD content from multiple content 
providers using multiple distribution systems. 

[0021] In one implementation of a method of the present 
invention, four main functional components, a metadata 
ingestion component, a file distribution tracking component, a 
file upload tracking component, and a usage reporting 
component, enable a VOD management system to manage and 
distribute metadata and to track multimedia asset data files. 
All of the multimedia asset data files are tracked by a VOD 
management system 110, and may be assigned a unique workflow 
identification number to allow the VOD management system 110 to 
track the location and status of the file at any time. 
Communication between the functional components and the VOD 
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management system 110 may be accomplished via simple request 
response messaging application program interfaces ("APIs")/ or 
data exchanges using known XML formats. 

[0022] Using the methods of the present invention, 
metadata 106 and multimedia asset data files 108 from content 
providers and MSOs are ingested and validated. Turning to 
Figure 1, the components required to implement the metadata 
ingestion functional component of a method of the present 
invention are illustrated. A VOD management system 110 is 
configured to accept data and instructions from content 
providers or content networks 102 (unless otherwise noted, 
references herein to "content provider" are intended to refer 
to either a content provider or a content network/content 
aggregator) and MSOs 112. Specifically, the VOD management 
system 110 receives metadata 106 of various formats, and tracks 
multimedia asset data files 108 with which the metadata 106 is 
associated. A multimedia asset data file 108 may include 
content (such as, e.g., a feature file, a preview file, a 
graphics file, and the like; these may be referred to herein as 
"elements"), basic metadata associated with each element that 
provides information on the elements that helps confirm 
accuracy of delivery. The feature may be in any suitable 
format, such as, e.g., a MPEG file. Multimedia asset data 
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files 108 for movies, for example, may include graphics files 
of movie poster art or box covers. These graphics files may be 
any suitable format, such as, e.g., JPEG, TIFF, GIF, and the 
like . 

5 [0023] In a preferred embodiment, a web-based user 

interface 104 is provided for each content provider 102 to 
communicate with the VOD management system 110. The content 
provider 102 may transmit metadata to the VOD management system 
110 using a variety of formats, including, but not limited to, 

10 CableLabs XML, MOD, tab delineated files, and the like. Using 
the interface 104, the content provider 102 preferably tracks 
the transmission of multimedia asset data files 108 and 
transmits related metadata 106 using a suitable internet 
protocol, such as, e.g., HyperText Transfer Protocol ("HTTP") 

15 or File Transfer Protocol ("FTP") . For example, the content 
provider 102 may use the interface 104 to provide the VOD 
management system 110 with the name of the multimedia asset 
data file 108, a description of the file 108, the MSOs 112 
scheduled to receive the file 108, a target ship date for 

20 delivery of the file 108 to the specified MSOs 112, an actual 
ship date for delivery of the file 108 to the MSOs 112, and a 
delivery method for the file 108. The content provider 102 may 
also specify that different multimedia asset data files 108 
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form a single delivery group that contains several different 
features. The delivery group may, for example, contain several 
different movies and, accordingly, the multimedia asset data 
files 108 that are associated with those movies. As one 
5 example, the content provider 102 may create a delivery group 
entitled "July New Releases" and place within that delivery 
group the multimedia asset data files 108 associated with the 
new release movies scheduled to be released on that July. 
References herein to the transmission and delivery of 
10 multimedia asset data files 108 individually will also be 
understood to refer to the transmission and delivery of 
multimedia asset data files 108 in delivery groups. 

[0024] Using the interface 104, the content provider 
102 also specifies the calendar dates during which a particular 

15 multimedia asset data file 108 will be made available for 

delivery to MSOs 112 (and, therefore, for purchase by end users 
of the MSOs 112) . The content provider 102 may also assign a 
delivery priority to each multimedia asset data file 108 (or 
delivery group of multimedia asset data files 108) in order to 

2 0 allow the VOD management system 110 to allocate bandwidth to 
various multimedia asset data files 108. The allocation of 
bandwidth is particularly important when multimedia asset data 
files 108 are being transmitted via satellite delivery. To 
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facilitate the reception of multimedia asset data files 108 
from content providers 102, the VOD management system 110 is 
configured to integrate with legacy/existing asset management 
systems, such as, e.g., digital asset management systems 
5 available from WebWare Corporation (Sausalito, California) . 
During the data entry process, information is validated for 
correctness and completeness. 

[0025] As part of the title assembly workflow, 
multimedia asset data files 108 are registered with the VOD 

10 management system 110. Each content provider 102 is assigned a 
provider ID, and transmissions from the content provider 102 to 
the VOD management system 110 include the provider ID. Based 
upon the provider ID and a provider asset ID (i.e., an asset 
identifier provided by the content provider 102) , the VOD 

15 management system 110 assigns a globally unique identifier to 
the corresponding multimedia asset data file 108 to identify 
the file 108 throughout the content delivery process. 

[0026] As with the content providers 102, MSOs 112 
preferably communicate with the VOD management system 110 using 
20 a web-based user interface 114. The VOD management system 110 
coordinates the metadata 106 and multimedia asset data file 108 
ingestion and validation process using a workflow customizable 
by the MSO 112. In general, the workflow requires that the 
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metadata 106 and multimedia asset data file 108 comply with 
values and business rules provided by the MSO 112 before the 
VOD management system 110 will determine that the metadata 106 
and multimedia asset data file 108 was properly received. 

5 [0027] In one embodiment, the interface 114 enables a 

MSO 112 to enter, edit, and manage business rules using a text 
editor. In another embodiment, the interface 114 enables a MSO 
112 to enter, edit, and manage business rules using a graphic 
user interface 114. Using the interface 114, a MSO 112 

10 provides scheduling and business rules to the VOD management 
system 110, including, but not limited to, ratings filters, 
pricing rules, category rules, platform conversion rules, 
electronic program guide ("EPG" ) data, storage allocations for 
VOD servers, scheduling approval guidelines, and the like. The 

15 business rules are preferably contained within their own 

grouping elements, such as, e.g., ratings filters are grouped 
together and pricing rules are grouped together. The VOD 
management system 110 preferably stores business rules as XML 
documents, and identifies business rules with particular MSOs 

20 112. Alternatively, the VOD management system 110 may store 
business rules in a database rather than as XML files. When 
the VOD management system 110 receives metadata 106 and 
multimedia asset data files 108 from a content provider 102, 
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the VOD management system 110 validates the metadata 106 and 
files 108 using the business rules provided by the MSO 112. 
Descriptions of several exemplary business rules follow. 

[0028] Ratings filters are rules used to block the 
delivery of files 108 based upon a rating, such as, e.g., a 
MPAA rating. A rating filter should consist of a rating and an 
associated action, such as "blocked" to specify that features 
with this rating should not be delivered or "unblocked" to 
specify that features with this rating may be delivered. For 
example, a particular deployment may use a ratings filter in 
order to prevent the- delivery of adult content. The default 
behavior associated with a rating is "unblocked." That is, if 
a rating filter does not exist for a particular rating, the VOD 
management system 110 will consider features with that rating 
as "unblocked." 

[0029] Pricing rules allow a MSO 112 to determine 
and/or override a default price associated with a file 108. 
When used, pricing rules may allow a file 108 to receive a 
different price at each MSO deployment. Figure 2 illustrates a 
price calculation process using pricing rules as implemented by 
the systems and methods of the present invention. During the 
creation of a multimedia asset data file 108, the content 
provider 102 assigns a default pricing model to the file 108. 
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The pricing model will tag the file 108 for purposes of pricing 
and assign the file 108 a default price. The pricing model may 
be specific to a particular MSO 112, and may also include a 
name for the pricing model (e.g., "Kids," "New Release," 

1 

5 "Library," "Adult," "Top Picks," "Custom," and the like), a 
string description of the pricing model, a default price 
associated with the pricing model, and a client ID or other 
identification to associate the pricing model with a particular 
MSO 112. In one embodiment, the assignment of the pricing 

10 model will be independent of the feature associated with the 
file's 108 genre and/or categorization. If needed, a MSO 112 
or a content provider 102 will be able to assign a customized 
pricing model to the multimedia asset data file 108. 
Additionally, the VOD management system 110 can associate a 

15 pricing override with a pricing model. A pricing override will 
consist of a pricing model name and an associated price. A 
feature's price is first set using the default price associated 
with its assigned pricing model (step 202) . The VOD management 
system 110 next analyzes the multimedia asset data file 108 to 

2 0 determine whether a custom pricing model has been assigned to 
the file 108 (step 204). In the case where the file 108 has 
been assigned to a custom pricing model, the feature's 
specially assigned price is used instead of the default price 
(step 206) . If the file 108 has not been assigned a custom 
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pricing model, the VOD management system 110 determines whether 
a pricing rule, such as a pricing override rule, has been 
assigned to the file 108 (step 208) . If so, the VOD management 
system 110 assigns an override price to the file 108 (step 
5 210) . Upon completion of the aforementioned steps, the VOD 

management system 110 determines a final price for the file 108 
(step 212) . 

[0030] Category rules allow a deployment's metadata 
file to receive only those categories that are locally defined. 
10 When used, category rules allow a file 108 to be categorized 
differently across a MSO 112 network. 

[0031] Platform specialization or conversion rules 
allow the VOD management system 110 to structure an electronic 
program guide ( "EPG" ) to a custom format that may be designated 

15 by each MSO 112 or MSO location (deployment) . In one 

embodiment, a minimum of three sets of platform conversion 
rules are used to provide for three different displays 
available for a MSO's 112 EPG. The platform conversion rules 
are used by the VOD management system 110 to convert the 

2 0 presentation -format of metadata associated with a feature into 
a display format that is specific to the needs of a particular 
MSO 112. The VOD management system 110 also utilizes the 
platform conversion rules to generate an appropriate platform 
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compliant XML for a MSO 112, and may also use the conversion 
rules to handle image conversion for a particular MSO 112. In 
one embodiment, the platform conversion rules are hard coded. 
In another embodiment, the platform conversion rules utilize a 
5 script design that facilitates changes to any particular set of 
conversion rules. 

[0032] The custom EPG function of the VOD management 
system 110 is also usable to generate targeted promotions. For 
example, the EPG for a MSO 112 may be customized with 
10 multimedia promotional elements including detailed information 
about available VOD features and reviews of the available VOD 
features . 

[0033] In another embodiment, the VOD management system 
110 is capable of customizing the EPG to allow functionality 

15 similar to an interface provided by a DVD feature. The DVD- 
like functionality ' that the VOD management system 110 adds to 
the EPG includes allowing an end user to choose alternate 
endings of a feature or different commentary tracks for a 
feature. Accordingly, the VOD management system 110 is capable 

20 of processing and distributing multimedia asset data files 108 
that incorporate multiple language tracks, multiple video 
assets {e.g., alternate endings, deleted scenes, and the like), 
multiple graphics, and an extensible metadata scheme to include 



IR1:1046148.3 



PATENT 
505, 807-58 

any additional text that may be desired for a given multimedia 
asset data file 108 to provide DVD-like features. When 
delivering these multimedia asset data files 108, the VOD 
management system 110 is capable of customizing a particular 
5 EPG to enable an end user to enable the DVD- like features 
included with the file 108. 

[0034] The VOD management system 110 enables users to 
view and analyze metadata and scheduling information. For 
example, when multimedia asset data files 108 are scheduled to 

10 be delivered in delivery groups, the user interface 104 enables 
the content provider 102 to locate an existing/scheduled 
delivery group by searching for one of the following 
parameters: the name of a specific delivery group; delivery 
groups that contain a specific multimedia asset data file 108, 

15 e.g., delivery groups that contain a specific movie or other 

feature; delivery groups that are scheduled for a specific MSO 
112; the status of delivery groups, e.g., in progress, 
approved, completed, and the like; or the scheduled target 
delivery date. The level of information available to any 

20 particular user will vary depending on that user's clearance 
level . 

[0035] In another embodiment, the VOD management system 
110 incorporates an advertising server that is capable of 
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implementing dynamic advertising play lists that are targeted 
to individual end users. The advertising server is preferably 
in operable connection with the VOD server 125 of a MSO 112. 
The VOD management system 110 is configured to analyze the 
5 usage data provided by the VOD server 12 5 and generate usage 
reports in order to deliver information necessary for the 
advertising server to personalize advertising to an end user. 
For example, the VOD management system 110 analyzes the usage 
reports to build business rules that are used to deliver data 

10 used and analyzed by the advertising server to insert ads into 
content delivered to an end user. The advertising delivered to 
a particular end user is preferably determined based upon the 
end user's viewing habits and characteristics. For example, 
the VOD management system 110 may generate an advertising play 

15 list that includes advertising relating to sports or action 

movies that may be inserted into content to be delivered to an 
end user whose viewing characteristics include a number of 
action movies. The play list is then delivered to the 
advertising server, and the advertising server analyzes 

20 advertising inventory to create a suitable matching ad that is, 
in turn, inserted into a feature ordered by the end user and 
delivered by the VOD server 125. In another embodiment, the 
advertising play list generated by the VOD management system 
110 includes advertising that is manually inserted by either 
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the MSO 112 or a content provider 102 to provide an on-demand 
advertising function that enables the specific targeting of 
advertising to certain end users. 

[0036] In another embodiment, the VOD management system 
5 110 enables campaign management functionality designed to make 
possible for a content provider 102 or MSO 112 to control the 
marketing and branding of its content. Features provided by 
the campaign management functionality include enabling a 
content provider 102 or MSO 112 to bundle selected groups of 

10 multimedia asset data files 108, set pricing for multimedia 

asset data files 108, determine promotions for multimedia asset 
data files 108, and provide closed-loop reporting. For 
example, a content provider 102 or MSO 112 may analyze a usage 
report provided by the VOD management system 110 to select 

15 certain multimedia data asset files 108 based upon, e.g., end 
user viewing habits, and then use the campaign management 
functionality to bundle selected multimedia asset data files 
108, set pricing for selected files 108, and set promotions for 
selected files 108. An additional feature that may be provided 

2 0 by the campaign management functionality is to increase a 
content provider's 102 (and MSO's 112) visibility into the 
content preparation and distribution process while abstracting 
away details such as formats, bit rates, and regional business 
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rules. Also, the campaign management functionality may be 
configured to allow a content provider 102 to implement 
advertising supported VOD. In another embodiment, the VOD 
management system 110 is configured to integrate with third 
party campaign management tools. 

[0037] Using the methods of the present invention, the 
multimedia asset data files 108 are distributed to MSOs 112. 
Turning to Figure 3, the components of a system required to 
implement the asset distribution functional component are 
illustrated. A multimedia asset distribution system or 
network ( 11 ADS" ) 120 facilitates the delivery of multimedia asset 
data files 108 from content providers 102 to the MSO 112. Each 
content provider 102 uses a pitcher appliance 122 to transmit 
multimedia asset data files 108 to the MSO 112. The multimedia 
asset data files 108 may be scheduled for individual 
transmission to the MSO 112, or a group of multimedia asset 
data files 108 may be scheduled for transmission as part of a 
delivery group to the MSO 112. Although only one pitcher 122 
is illustrated, it will be appreciated that each content 
provider 102 may implement a plurality of pitchers 122. 

[0038] The pitcher 122 is a hardware and software 
component that is responsible for initiating and coordinating 
the transfer of a multimedia asset data file 108 to the MSO 
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112. The pitcher 122 may be implemented using any suitable 
server, such as, e.g., servers available form Compaq/Hewlett - 
Packard (Palo Alto, California) . In one embodiment, the 
pitcher 122 will deconstruct a multimedia asset data file 108 
5 into smaller elements in order to expedite the transfer of the 
multimedia asset data file 108 to the MSO 112. In a preferred 
embodiment, the pitcher 122 also augments the multimedia asset 
data file 108, and elements {e.g., feature, preview, and 
graphics files for multimedia asset data files 108 relating to 

10 the feature) thereof, with metadata 106. The pitcher 122 

transmits the elements of the multimedia asset data file 108, 
along with associated metadata 106, to a catcher appliance 124 
using any suitable satellite distribution channel 126. The 
satellite distribution .channel 126 may include, for example, an 

15 Internet Protocol ("IP") encapsulator that is coupled to both 
the pitcher 122 and a satellite uplink facility. Here, the IP 
encapsulator is configured to relay transmissions from the 
pitcher 122 to the satellite uplink facility. The satellite 
uplink facility then transmits the data elements of the 

20 multimedia asset data file 108 to various orbiting satellites, 
which in turn transmit the elements to a satellite downlink 
facility of the MSO 112. 
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[0039] The MSO 112 implements catcher appliances 124 
coupled to its satellite downlink facility and configured to 
receive transmissions originating from content providers 102. 
To process multiple data transmissions from multiple content 
5 providers 102, the MSO 112 may utilize a farm containing a 
plurality of catchers 124, or use multiport catchers 124 
configured to simultaneous receive a plurality of transmissions 
from multiple content providers 102. An example multiport 
catcher suitable for use with the present invention is 
10 disclosed in co-pending and commonly assigned application 

entitled "Multicast Distribution System" filed on October 22, 
2003, U.S. Application Serial Number 10/692,082, which is 
incorporated herein by reference. 

[0040] Each catcher 124 is a hardware and software 
15 component that may be based on servers such as those available 
from Compaq/Hewlett -Packard (Palo Alto, California) , Dell 
Computer (Round Rock, Texas) , and IBM (Armonk, New York) . In a 
preferred embodiment, the catcher 124 will include a minimum of 
256 MB of random access memory ("RAM"), a plurality of 
2 0 peripheral component interconnect ("PCI") expansion slots to 
support the integration of a data receiver card (with a 
multiport catcher 124 having as many PCI slots as the desired 
number of data receiver cards within the catcher 124) , and at 
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least one data receiver card capable of receiving satellite 
transmissions. Multiport catchers 124 will implement a 
plurality of data receiver cards. In one embodiment, universal 
serial bus ( U USB" ) ports are provided on the catcher 124 and 
5 allow for the addition of functionality via external 

peripherals. Additionally, the catcher 124 includes at least 
120 GB of storage capacity. For robustness and reliability, 
the storage may be allocated across a redundant array of 
inexpensive disks ( "RAID" ) array, and to minimize cost IDE 
10 storage technology may be utilized. Furthermore, the catcher 

124 may incorporate a form of out -of -band management that would 
allow for dial-up access, cold start-up, or manual rebooting of 
the catcher 124 if necessary. 

[0041] In addition to satellite transmissions, the 
15 catcher 124 is preferably also able to receive multimedia asset 
data files 108 locally using physical media (i.e., tapes or 
disks) , a local network, or a terrestrial -based network. 
Accordingly, the catcher 124 may incorporate a digital 
versatile disc ( "DVD" ) based drive or other suitable local data 
2 0 drive. Similarly, the catcher 124 may be coupled to a FTP 

server to obtain multimedia assets from the FTP server. The 
catcher 124 may further include a removable disk drive to allow 
for local exchange of data via removable disks. 
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[0042] The catcher 124 is configured to confirm 
successful receipt of transmissions originating from a pitcher 
122. Accordingly, the catcher 124 is operably coupled to the 
VOD management system 110 via a network connection 128. The 
network connection 128 may be any suitable communications 
network, such as, e.g., an internet-based network, a public 
switched telephone network ("PSTN") , a corporate virtual 
private network ("VPN") and the like. To connect to the 
network connection 128, the catcher 124 preferably incorporates 
a network interface ("NIC") card that enables the catcher 124 
to utilize 10/100 ethernet, or a similar high speed network 
connection. Alternatively, the catcher 124 may use a standard 
modem to connect to the network connection 128. Using the 
network connection 128, the catcher 124 acknowledges to the VOD 
management system 110 a successful or failed transmission, and 
in the event of a failed transmission, requests a complete or 
partial retransmission of the multimedia asset data file that 
was not properly received. In a similar fashion, a network 
connection 127 between each pitcher 122 and the VOD management 
system 110 is provided. The pitcher 122 utilizes the network 
connection 12 7 to inform the VOD management system 110 when a 
transmission is initiated by the pitcher 122. 
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[0043] Copending and commonly assigned application 
entitled "Multicast Distribution System" filed on October 22, 
2003, U.S. Application Serial Number 10/692,082, which is 
incorporated herein by reference, discloses additional details 
5 of an asset distribution system suitable for use with the 
systems and methods of the present invention, and has been 
expressly incorporated by reference. 

[0044] Figure 4 illustrates an example workflow that is 
implemented by the asset distribution functional component of 

10 the present invention. As noted herein, the pitcher 122 of a 

content provider 102 transmits a multimedia asset data file 108 
to the catcher 124 in elements. Figure 4 shows the 
distribution of a multimedia asset data file 108 using three 
elements, namely a feature element with related basic metadata, 

15 a preview element with related basic metadata, and a graphic 

element with related basic metadata. The pitcher 122 transmits 
the movie/feature element (step 402), and the movie/feature 
element is subsequently received by the catcher 124 of the MSO 
112 (step 404) . The catcher 124 analyzes the movie/feature 

2 0 element and related metadata to determine whether the element 

was properly received (step 406) . If the movie/feature element 
was not properly received, the catcher 124 transmits an alarm 
to the VOD management system 110 to inform the VOD management 
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system 110 that a retransmission of the movie/feature element 
is required (step 408) . If the movie/feature element was 
properly received, the catcher 124 stages the movie/feature 
element while awaiting delivery of the other elements of the 
5 multimedia asset data file 108 (step 410) . Next, the pitcher 
122 transmits the preview element (step 412) , and the preview 
element is subsequently received by the catcher 124 (step 414) . 
The catcher 124 analyzes the preview element and related 
metadata to determine whether the element was properly received 

10 (step 416) . The catcher 124 transmits an alarm to the VOD 

management system 110 if the preview element was not properly 
received, thereby informing the VOD management system 110 that 
a retransmission of the preview element is necessary (step 
418) . If the preview element was properly received, the 

15 catcher 124 stages the preview element while awaiting delivery 
of the other elements of the multimedia asset data file 108 
(step 420) . Finally, the pitcher 122 transmits the graphic 
element (step 422) , which is received by the catcher 124 (step 
424) . The catcher 124 analyzes the graphic element and related 

2 0 metadata to determine whether the element was properly received 
(step 426) . If the graphic element was not properly received, 
the catcher 124 transmits an alarm to the VOD management system 
110, informing the VOD management system 110 that a 
retransmission of the graphic element is required (step 428) . 
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If properly received, the catcher 124 stages the graphic 
element along with the other already received elements of the 
multimedia asset data file 108 (step 430) . It will be 
appreciated that a greater or smaller number of elements may be 
used, and that the elements may be transmitted in any order. 

[0045] After receiving all of the elements of the 
multimedia asset data file 108, the catcher 124 confirms 
successful delivery of the multimedia asset data file 108 to 
the VOD management system 110 and waits for a request from the 
VOD server 125 to release the multimedia asset data file 108 to 
the VOD server 125. Using the master schedule generated by the 
VOD management system 110, the catcher 124 then releases the 
file 108 to the VOD server 125 (step 436) . The VOD management 
system 110 tracks the request and delivery of metadata 106 and 
the file 108 to the VOD server 125. 

[0046] The methods of the present invention are also 
used to coordinate the upload of content from several content 
providers, as well as provide visibility into the success or 
failure of the upload process. The process of uploading 
content to a VOD server 125 is driven by the VOD server 125 and 
coordinated by the VOD management system 110. Working with the 
VOD management system 110 and the catcher or catchers 124, the 
VOD server 12 5 coordinates the upload of the multimedia asset 
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data files 108 that are received from the content providers 
102, and also provides visibility into the success or failure 
of the upload process. The process of distributing a 
multimedia asset data file 108 starts with the file 108 being 
5 assigned to a distribution schedule. Scheduling involves 
selecting distribution dates (including a start and an end 
date), selecting the appropriate set of VOD deployments (i.e., 
head ends), and assigning marketing information such as, e.g., 
pricing and categorization. In addition, scheduling may also 
10 involve the selection of the multimedia asset data files 108 
that should be distributed to end users. Prior to the 
distribution of a multimedia asset data file 108 to a 
particular end user, the scheduling information for the file 
108 must be approved by the VOD management system 110. 

15 [0047] Turning to Figure 5, an example workflow 

implemented by the content upload functional component of the 
system is illustrated. The VOD upload coordination process is 
initiated by distributing a localized master schedule to each 
MSO 112. As shown in Figure 5, the VOD server 125 submits a 

2 0 schedule request to the VOD management system 110 of the system 
(step 502) . In this example, the VOD server 125 may initiate a 
schedule update request to the VOD management system 110 at a 
regular interval, such as, e.g., daily, hourly, and the like. 
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In response, the VOD management system 110 provides a 
customized or localized master schedule for the MSO 112 to the 
MSO's VOD server 125 (step 504) . In one embodiment, a file 108 
will be included as part of the master schedule once all of the 
5 following steps have been completed: the file 108 has been 

successfully received by the catcher 124, the content provider 
102 and MSO 112 have inserted all associated metadata 106 into 
the VOD management system 110, the content provider 102 or MSO 
112 has provided a date on which the file 108 and metadata 106 

10 should be uploaded to the VOD server 12 5 and that date or the 
business rules governing that date have been determined to be 
met by the VOD management system 110, and the MSO 112 has 
indicated the priority of the file 108 relative to other files. 
The master schedule is customized for each MSO 112 and reflects 

15 the status of the multimedia asset data files 108 that are to 

be delivered to each MSO 112 or MSO location (deployment) . The 
VOD server 125 then processes the schedule update it receives 
from the VOD management system 110 by modifying the localized 
master schedule. For example, the schedule update includes 

20 instructions for inserting and deleting files 108 from the 
master schedule and performing other updates to the master 
schedule. Similarly, the VOD server 125 may initiate and 
process metadata updates to change the title, pricing, 
category, description, and the like, of a multimedia asset data 
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file 108. The schedule allows the VOD server 125 to locate the 
elements of a multimedia asset data file 108 by providing 
locator URLs. The locator URLs may include a metadata URL that 
points to a location on the VOD management system 110 and an 
asset URL that points to a local FTP server or catcher 124, for 
example. Because the schedule is configurable for each MSO 112 
and each deployment, the present invention is capable of 
coordinating the prioritization and scheduling of the delivery 
of multimedia asset data files 108 to each individual MSO 112 
or each individual MSO 112 deployment. Furthermore, the 
customized schedules are usable with the previously discussed 
custom EPG function to further customize the EPGs used by each 
MSO 112 or deployment. 

[0048] Multimedia asset data files 108 may be stored by 
the VOD management system 110 in either internal content 
locations (e.g., multimedia asset management ("MAM") systems 
that include large third party deep archive repositories) or 
external content locations (e.g., catchers 124 maintained by 
MSOs 112) . That is, the files 108 themselves can be physically 
located in any storage device or location, as long as the VOD 
management system 110 is able to track that location, such as, 
e.g., tracking the physical location of the file by reference 
to an asset locator URL (or asset URL) for that physical 
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location. The following discussion focuses on files 108 stored 
at external content locations, e.g., at catchers 124 maintained 
by MSOs 112. Here, to upload and process a multimedia asset 
data file 108, the VOD server 125 must retrieve the various 
5 elements of the multimedia asset data file 108 from a catcher 
124 (step 506) . The master schedule allows the VOD server 125 
to locate the elements of the multimedia asset data files 108 
(ex. feature, preview, graphic, metadata) that have been 
transmitted to the catcher 124 by providing metadata URLs for 

10 each multimedia asset data file 108. The URL used to retrieve 
the elements of the multimedia asset data file 108 will vary 
depending on the caller location, access protocol, and 
security. The specific machine that is accessed to obtain an 
element will depend on a caller location. The specific machine 

15 accessed by the VOD server 125 will generally be the catcher 
124, but may be an archive repository for internal content. 
The URL further indicates the appropriate protocol used to 
retrieve a element from a particular machine (e.g., file://, 
http://, ftp://, https://, and the like). Al so, the URL 

20 provides a user or caller with information necessary to 
authenticate with a content host. 

[0049] The VOD server 125 submits the metadata URL, 
which may contain a server ID and an asset ID, for a particular 
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multimedia asset data file 108 to the VOD management system 
110, and the VOD management system 110 in turn provides asset 
URLs, with data regarding the physical location of files, to 
the VOD server 12 5 (step 5 08) . In one embodiment, the VOD 
5 management system 110 may generate responsive metadata on-the- 
fly, thereby allowing for metadata localization and permitting 
vendor-specific adjustments. After receiving the asset URLs 
from the VOD management system 110, the VOD server 12 5 analyzes 
the asset URLs to determine whether the data was properly 

10 received (step 510) . If the VOD server 125 determines that the 
asset URLs were not properly received, the VOD server 12 5 
transmits an alarm to the VOD management system 110 to request 
a retransmission of the asset URLs (step 512) . If the asset 
URLs are properly received, the VOD server 12 5 then loads the 

15 metadata (step 514) . The VOD server 125 determines whether the 
metadata was properly loaded (step 516) , and in the event of a 
failure to properly load the metadata the VOD server 125 
transmits an alarm signal to the VOD management system 110 
(step 518) , thereby informing the system that follow-up and 

2 0 diagnosis is required. 

[0 050] The asset URLs are used by the VOD server 125 to 
retrieve the elements of the multimedia asset data file 108 
that have been transmitted to the catcher 124 . In the 
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illustrated example in which movie/ feature, preview, and 
graphics elements were transmitted to the catcher 124, using 
the asset URLs received from the VOD management system 110, the 
VOD server 125 initiates a series of file transfers, which may 
be FTP transfers for example, from the catcher 124 in order to 
load the elements of the multimedia asset data file 108. 

[0051] • For the movie/feature element, the VOD server 
125 submits the asset URL corresponding to the movie/feature 
element to the catcher 124, and the catcher 124 responds by 
transmitting the movie/feature element to the VOD server 125 
(step 520) . After receiving the movie/feature element from the 
catcher 124, the VOD server 125 analyzes the movie/feature 
element to verify that the element was properly received (step 
522) . If the movie/feature element was not properly received, 
the VOD server 12 5 transmits an alarm to the VOD management 
system 110 and/or the catcher 124 (step 524) . If the 
movie/feature element is properly received, the VOD server 125 
begins to load the element (step 526) . The VOD server 125 
determines whether the movie/feature element was properly 
loaded (step 528) . In the event of a failure to properly load 
the movie/f eature element, the VOD server 125 transmits an 
alarm signal to the VOD management system 110 (step 530) , 
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thereby informing the system 110 that follow-up and diagnosis 
is required. 

[0052] The VOD server 125 retrieves the preview element 
of the multimedia asset data file 108 in a similar manner. For 
example, the VOD server 12 5 submits the asset URL corresponding 
to the preview element to the catcher 124, and in response the 
catcher 124 transmits the preview element back to the VOD 
server 125 (step 532) . After receiving the preview element 
from the catcher 124, the VOD server 125 analyzes the element 
to determine whether the preview element was properly received 
(step 534) . If the preview element was not properly received, 
the VOD server 125 transmits an alarm to the VOD management 
system 110 (step 536) . Otherwise, the VOD server 125 begins to 
load the preview element (step 538) . The VOD server 12 5 
determines whether the preview element was properly loaded 
(step 540) . In the event of a .failure to properly load the 
preview element, the VOD server 125 transmits an alarm signal 
to the VOD management system 110 (step 542) , thereby informing 
the system 110 that follow-up and diagnosis is required. 

[0053] In the example workflow, the VOD server 125 also 
retrieves a graphic element of the multimedia asset data file 
108. As with the movie/feature and preview elements, the VOD 
server 12 5 submits the asset URL corresponding to the graphic 
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element to the catcher 124, and in response the catcher 124 
transmits the graphic element back to the VOD server 125 (step 
544) . After receiving the graphic element from the catcher 
124, the VOD server 125 determines whether the element was 
5 properly received (step 546) . If the graphic element was not 

properly received, the VOD server 125 transmits an alarm to the 
VOD management system 110 (step 548) . If the graphic element 
was properly received, the VOD server 12 5 begins to load the 
element (step 550) . Next, the VOD server 125 determines 
10 whether the graphic element was properly loaded (step 552) . In 
the event of a failure to properly load the graphic element, 
the VOD server 125 transmits an alarm signal to the VOD 
management system 110 (step 554), thereby informing the system 
110 that follow-up and diagnosis is required. 

15 [0054] The upload process terminates when the VOD 

server 125 confirms the success or failure of a particular 
attempt to load all of the elements of the multimedia asset 
data file 108 (step 556) , and the file 108 is completely loaded 
on the VOD server 12 5 (step 558) . In order to improve 

20 visibility of the upload process, additional status updates may 
occur earlier in the upload process, for example, upon 
completion of the FTP transfer of one of the elements of the 
multimedia asset data file 108. Additionally, the VOD server 
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12 5 preferably continuously updates the status of the 
multimedia asset data file 108 with the VOD management system 
110 throughout the upload process. 

[0055] By verifying the proper reception and loading of 
5 the elements of the multimedia asset data file 108 throughout 
the upload process (ex. steps 510, 516, 522, 528, 534, 540, 
546, 552), the system 110 provides real-time or near real-time 
verification of content delivery failures, as well as 
visibility into the VOD server 125 upload operations as they 
10 pertain to the content delivery process. 

[0056] The methods of the present invention are also 
used to aggregate usage information from each VOD deployment, 
and thereby provide visibility into the use of the multimedia 
asset data files 108. At regular intervals, the VOD server 125 

15 provides the VOD management system 110 with data on the 

features that are requested by the users of the MSO 112. Using 
this data, the VOD management system 110 prepares a usage 
report. To prepare the usage report, the VOD management system 
110 creates a master reporting database that includes usage 

2 0 information from across the MSO's 112 network. In one 

embodiment, the usage report is provided to the MSO 112 and the 

content providers 102 in the form of stock reports. 

Preferably, the MSO 112 has access to 'the entirety of the usage 
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report, whereas the content providers 102 have restricted 
access to the usage report. Here, the MSO 112 provides the VOD 
management system 110 with business rules to determine the 
extent to which any content provider 102 has access to the 
5 usage report. Additionally, the VOD management system 110 is 
capable of exporting the usage report, or the underlying data, 
to other systems in order enable the MSO 112 to conduct a more 
advanced analysis of the usage patterns of the features 
delivered by the VOD servers 125 to its users. The information 

10 and data contained in the usage report may include a listing of 
the multimedia content that has been licensed, the content that 
is available for distribution to the users, the estimated time 
a particular multimedia asset data file 108 will be delivered 
to the MSO 112, the time at which a multimedia asset data file 

15 108 was loaded on to a VOD server 125 of the MSO 112, the 

amount of storage on the VOD servers 125 that is allocated to 
any particular content provider 102, the revenue generated by 
any specific feature, and the like. Usage reports are capable 
of being searched and sorted using multiple criteria, 

20 including, e.g., content provider, studio, genre, region, and 
the like. Furthermore, in one embodiment, the VOD management 
system 110 incorporates preference engines that aid content 
. providers 102 and MSOs 112 target promotions and advertisings 
to certain users based upon the usage report. Additionally, 
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the VOD management system 110 is capable of supplementing the 
metadata of each multimedia asset data file 108 with data 
contained in the usage reports. For example, the metadata of a 
given multimedia asset data file 108 may be 
5 supplemented/augmented with detailed performance/usage 

information for that multimedia asset data file 108 that a 
content provider 102 or MSO 112 may later user for campaign 
management. For example, after analyzing the usage information 
for a multimedia asset data file 108, a content provider 102 
10 may elect to bundle that file 108 with other files 108, 

initiate promotional pricing for that file 108, and the like. 

[0057] To facilitate communication between the VOD 
management system 110 and applications used by the MSOs 112 and 
content providers 102, the VOD management system 110 will 

15 preferably implement a light weight web services API. The VOD 
management system 110 web service API is preferably implemented 
via XML over HTTP/HTTPS with requests initiated via HTTP "GET" 
and "POST" commands. Requests sent to the web services API may 
be initiated via a HTTP query string, with the web services API 

2 0 returning responses as XML documents. API query strings 
preferably consist of a protocol (HTTP or HTTPS) , a VOD 
management system 110 host and port, a root path (/nuns/) , a 
method name, and a query string. Access to the VOD management 
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system 110 web service API is handled via HTTP basic 
authentication. Remote applications preferably access the VOD 
management system 110 as a specific user. The VOD management 
system 110 will respond to the API call or refuse the 
5 connection depending on the VOD management system 110 roles 
(level of authorization) associated with the user/remote 
application. 

[0058] Preferably, the web services API will be capable 
of performing the following functions. The web services API 

10 will allow for an asset initialization call that enables a 

content provider 102 to register a multimedia asset data file 
108 with the VOD management system 110. A pitcher confirmation 
call may be used by a pitcher 122 to signal to the VOD 
management system 110 that a multimedia asset data file 108 has 

15 been successfully pitched. A catcher confirmation call may be 
used by a catcher 124 to signal to the VOD management system 
110 that a multimedia asset data file 108 has been successfully 
caught. Additionally, in the event of a catch or validation 
failure, the catcher 124 may use the catcher confirmation call 

20 to transmit an error message to the VOD management system 110. 
A schedule request call may be used by the VOD server 125 to 
request a schedule from the VOD management system 110. A 
metadata request call may be used by the VOD server 125 to 
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request localized package metadata from the VOD management 
system 110. A package confirmation call may be used by the VOD 
server 125 during the upload process in order to communicate, 
to the VOD management system 110, status changes associated 
with the multimedia asset data file 108 during the upload. The 
VOD server 125 may also use a reporting call to deliver usage 
reporting statistics, to the VOD management system 110, 
relating to the delivery of multimedia asset data files 108 to 
end users of the MSO 112. In a preferred embodiment, the web 
services API returns an XML document in response to any of the 
aforementioned calls, if a response is necessary. The response 
may also include standard HTTP status or error codes. 

[0059] Turning to Figure 6, the physical components 
required to implement the systems and methods of the present 
invention are illustrated. The VOD management system 110 
preferably includes a VOD management point of presence ("POP") 
130 and a VOD management network operations center ( u NOC" ) 132. 
The VOD management POP 13 0 is preferably a high availability 
data center with redundant power and cooling systems. The 
supporting infrastructure for the VOD management POP 130 will 
also include redundant application and database servers, server 
backup systems, high availability switching gear, and a 
dedicated firewall. The VOD management NOC 132 is utilized to 
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monitor the VOD management system 110. The infrastructure to 
support and implement the VOD management NOC 132 is housed in a 
location in close proximity to (or in the same location as) the 
VOD management POP 130. To monitor the VOD management POP 130, 
the VOD management NOC 132 may use a simple network management 
protocol ("SNMP" ) management system. The MSO 112 has access to 
the VOD management system 110, preferably using an internet 
connection, in order to monitor the status of content being 
delivered to the catchers 124 of the MSO 112. The content 
providers 102 also preferably communicate with the VOD 
management system 110 via an internet connection. ■ 
Additionally, the content providers 102 preferably utilize a 
satellite-based system 134 to deliver multimedia asset data 
files 108 to MSOs 112 . 

[0060] Each MSO 112 preferably implements a catcher 124. 
to receive multimedia asset data files 108. The catcher 124 
then uploads the files 108 to a VOD server 125 as described 
herein. Using a suitable network, such as, e.g., a RF network 
136, the VOD server 12 5 then delivers the feature element or 
preview element obtained from the catcher 124 to end users, 
upon request by the end users, by delivering those elements to 
set top boxes 138. 
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[0061] Figure 7 illustrates the implementation layers 
of one embodiment of the VOD management system 110. The top 
level of boxes in Figure 7 are example application clients with 
which the VOD management system 110 may communicate. A web 
5 client 702 enables a user to communicate with the VOD 

management system 110 with a standard internet /web browser. A 
java message service ("JMS") client 704 enables a user to 
communicate with the VOD management system 110 using a JMS API. 
The JMS client 704 preferably utilizes established messaging 

10 formats, queues, and topics to initiate asynchronous calls 

between the client 704 and the VOD management system 110. An 
enterprise java beans ("EJB") client 706 utilizes J2EE 
enterprise java beans to initiate synchronous calls with the 
VOD management system 110. The EJB client 706 preferably 

15 utilizes established EJB home interfaces to construct objects, 
and uses session and entity bean interfaces to conduct 
synchronous calls. 

[0062] The VOD management system 110 incorporates 
several external interfaces to facilitate communication between 
20 the application clients and the VOD management system 110. The 
following are several external interfaces suitable for 
incorporation into the VOD management system 110. A web 
foundations interface 708 generates the user experience and 
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state needed to support a web client 702. The web foundation 
interface 708 may include java server pages ("JSPs"), servlets, 
wireless application framework ("WAF") components, and GUI 
beans. The web foundation interface 708 is preferably hosted 
5 by a J2EE application server's web container. A JMS API 710 is 
designed to receive and process JMS messages from a JMS client 
704 and from remote messaging clients. The JMS API 710 is 
implemented using EJB message driven beans. The JMS API 710 is 
preferably also implemented as wrappers around lower- level 

10 application engines. An EJB API 712 provides EJB wrappers 

around low-level application functionality. The EJB API 712 
provides a simple API that may be shared with developers, and 
may be implemented as stateless session EJBs . A web services 
API 714 provides a light weight synchronous API for interacting 

15 with the VOD management system 110, and is configured to 

interface with a web client 702. The web services API 714 
preferably utilizes XML over HTTP or simple object access 
protocol ( "SOAP" ) to access high level application 
functionality. In one implementation, the clients 702, 704, 

20 and 706 interact directly with the aforementioned external 
interfaces. Alternatively, the clients 702, 704, and 706 
interact with the external interfaces using a set of helpers 
called service adaptors 716. Service adaptors 716 simplify 
communication with the clients 702, 704, and 706 by 
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encapsulating any complexity associated with web, JMS, and EJB 
services , respectively. 

[0063] The next layers of Figure 7 represent internal 
system components of the VOD management system 110. These 
5 components are capable of running within a single process, 
although multiple instances may exist simultaneously within 
different processes. These components provide application 
interfaces for the internal operations and database schemes 
employed by the VOD management system 110. A component 

10 programmatic API 718 incorporates a set of java interfaces that 
address the VOD management system's 110 major functional 
components. The functions addressed by the component 
programmatic API 718 include managing workflow, maintaining 
database persistence, managing packaging of multimedia asset 

15 data files 108, localization of those files 108, and scheduling 
of the deployment of the files 108. A set of .engine 
implementations incorporate the bulk of the VOD management 
system's 110 programming code, and implements interfaces used 
by the system 110. The engine implementations include a 

2 0 business objects engine 72 0, a workflow engine 722, a packaging 
engine 724, a platform converter engine 726, a localization 
engine 728, and a scheduling engine 730. These engines provide 
flexible and extensible, functionality that may be customized to 
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address the needs of specific MSOs 112 and content providers 
102. 

[0064] The VOD management system 110 also makes use of 
both a metadata relational database 732 to store data. 
5 Information is preferably stored in the form of XML documents 
based on XML templates 734. 

[0065] The methods and systems of the present 
invention, although described with respect to VOD content 
delivery to MSOs 112, are also usable in other environments. 

10 For example, the methods and systems of the present invention 
may be used by a telephone company or a content delivery 
network. Because the methods and systems of the present 
invention are designed to support a continuum of platform 
delivery options, the methods and systems of the present 

15 invention may be used to support broadband delivery, 

interactive television content delivery, streaming content, 
cable video-on-demand, cable subscription video-on-demand, head 
end origination, and downloading of content. 

[0066] With specific regard to the delivery of 
2 0 broadband content and the use of PC-centric headends by MSOs 

112, the methods and systems of the present invention provide a 
mechanism for pre -caching broadband content by coordinating the 
delivery and propagation of assets regardless of origin or 
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destination. Broadband content that may be pre-cached by the 
present invention include IP video, non-video IP, web or 
internet content, and interactive television content and 
related applications. 

[0067] Though the invention has been described with 
respect to specific preferred embodiments, many variations and 
modifications will become apparent to those skilled in the art. 
It is therefore the intention and expectation that the appended 
claims be interpreted as broadly as possible in view of the 
prior art in order to include all such variations and 
modifications . 
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